State Monitor/Device design Notes
Overview:
The state monitor system should be able to monitor and log the status and alarms of machines in the ConSys system.
References:
Implementation:
The state monitor system is split into two parts:
State Device (CDeviceState): A standard ConSys device implementing the state system server. It should be possible to load new state monitor configurations to the device during the run. The state device connects to the ConSys system to obtain the data for the parameters to be monitored. The current state will be stored in a state document, CStDoc.
State monitor Program (StateMonitor): The state monitor program is a ConSys client program used to display the current state.
ConSysState.dll: This dll implements the state device and the common classes used in state device and StateMonitor program.
StateMonitor.exe: The state monitor display program. Implemented as a standard MFC MDI based program.
Class Model:
CState: Base class for all states. The state class is responsible for storing and handling the specific state. All state related attributes in the state class objects must be stored in a CStorage object - see below. The base class defines the standard attributes and methods for the state management.
CStDocument: The state document stores and handles all state dependent data, including the CState objects. The two descendants, CStDocumentApp and CStDocumentDev, are used in respective the StateMonitor application and the state device. The common data part in the base object are kept identical through the standard ConSys communication using the CStorage helper class described below. CStDocumentApp includes methods needed for the interactions with the user interface - see the CStView description. CStDocumentDev includes methods needed for the state monitoring and updating.
CStorage: This class is used to synchronise the data between the device and application part of the CStDocument. It contains all the state dependent data for the CState objects and the CStDocument. When the state objects are created they allocate memory in the CStorage class. Whenever the CStDocumentDev class has finished updating a change in the state, the CStorage class is invalidated. This will force the storage class at the server side to synchronise with the client side. The client side of the CStorage class notifies the CStDocumentApp class whenever the data has change. This in turn let the CStDocumentApp class notify all its views to update their data.
CStView: The CStView class is used to display and browse the data in CStDocumentApp. The CStDocumentApp/CStView class pattern follows the standard MFC document/view behaviour. All CState classes have a related view class, by convention named CView<StateClassName> to display its data.
CController: This object is used by the CDeviceState. It is responsible for maintaining and controlling a CStDocumentDev. The controller includes general attributes with information of its current mode (undefined, inactive, active), the overall status, the name of state monitor etc. When the controller mode is undefined or inactive, it accepts new CStDocumentDev configurations to be send to it. When activated, the CStDocumentDev can not be changed.
CDeviceState: This class is the core class for handling the state system. It is implemented as a standard ConSys device. The device can contain an unlimited number of controllers (CController). The general attributes including current mode and overall state from controllers can be read by all ConSys applications using standard ConSys data types and addressing. Specialised command and data structures are used to operate and maintain the controllers from the StateMonitor application. The configuration of the device is stored to a device setup file whenever it is changed. This setup file is loaded whenever the device is created from the ConSysLoader. The primary address key for all the needed address types is a string. This string contains a short unique name specifying a controller.
The device adressing:
Parameter name (s0) |
parameter |
Suggested |
Parameter name |
Data Type |
Interpretation |
Comment |
<name> |
0 |
|
|
|
|
|
Notes:
- Configuration files for each controller - placed in a directory specified in the setup. Named as the controller name.
Implementing a new state type, guidelines
- Create the CState derived class
- Create a corresponding CContent derived class
- Create a property page class to set up, use it in CStateXX::EditState()
- Add the new state to the CStateConstructor class:
* Increment NUMBER_OF_STATE_CLASSES, and define a new state class constant
* Update the CreateState and GetName methods
Last Modified 11 January 2019